Merge 还是 Rebase？这是个问题
事实上，虽然方式不同，但是git rebase 和 git merge 做的是同一件事。两者都是将一个分支的git提交整合到另一个分支中，但它们各自如何达到预期的结果，我们将在本文的范围内进行讨论。
首先，让我们深入研究一下这两个命令，以便找到最适合你的工作流程。
Git Merge
Git merge 将源分支的内容与目标分支进行整合。因此，只有目标分支被改变，而源分支的历史记录保持原样。换句话说，进行合并的时候，您的 HEAD 分支会生成新的 git commit，并保持历史commit。
优势
使用方式简单。
保留源分支的原始上下文。
保留提交历史和时间顺序。
将源分支的commit与另一个分支的commit分开。
劣势
大量的commit合并使历史记录变得混乱，从而使Git仓库的可视化图表中出现了包含无用信息的彩虹分支线（可能需要修改）。
Git Rebase
Git rebase 将所有的改动合并成一个补丁，并将补丁整合到目标分支中。merge和rebase的最重要的区别是后者清理历史提交记录。在从一个分支转移到另一个分支的过程中，不需要的部分会被删除，以保持线性提交记录。如果你在当前功能分支中需要包含主分支的最近更新，但主分支的历史必须保持干净时，这个命令就很方便了。
rebase将一个分支的变化重写到另一个分支，而不需要创建新的提交记录。
优势
保证线性提交记录和可读性，清除复杂的历史记录。
清理commit，使其成为一个commit。
劣势
对pull请求不起作用，因为你无法看到团队成员分别做了哪些改动。
可以隐藏上下文。
什么时候Merge什么时候Rebase
现在你已经区分了两种策略，让我们来讨论用例。
调查
在做出决定之前，仔细调查总是一个好主意。需要注意的是，所选择的策略应该与你的工作流程相匹配。一种工作流程策略对某个团队来说可能很好，而对另一个团队来说可能是致命的。因此，在选择某个策略之前，要考虑其优劣。
独立工作 vs 团队合作
如果你是单独工作，选择rebase而非merge可能会更方便。如果你与其他成员共享分支，你从该分支中获取更新，rebase 过程将产生不一致。
一定要考虑到merge保留了提交记录，而rebase则重写了提交记录!
在基于功能的工作流的情况下，git merge可能是你团队的正确选择。它还能帮助你避免还原或重置任何东西。
merge的结果，不同的功能保持隔离，不会干扰现有的提交历史。如果优先考虑的是保持一尘不染的提交记录，那么git rebase是一个更合适的版本，以避免不相关的提交。
冲突
revert rebase比revert merge要困难得多，因为rebase冲突时revert 一次提交，而merge冲突时需要revert全部提交。Git允许预览合并分支时的情况。
然而，不要乱用rebase! 除非你知道自己在做什么，否则不要rebase。不正确的rebase会让你陷入困境，导致严重的后果。
永远记住不要在共享分支上rebase。
总之，rebase和merge通过选择不同的方式提供了相同的结果。每种方式都有其独特之处。我之蜜糖，彼之砒霜，对来某种情况说是非常有用的方式，但对另一种情况来说可能是致命的。仔细调查可以防止出现混乱。因此，始终要考虑到当前的情况以及你和你的团队可能遇到的障碍。
原文地址：
https://levelup.gitconnected.com/merge-or-rebase-thats-the-problem-11d65944b7e
本文由高可用架构翻译，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
长按二维码 关注「高可用架构」公众号